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CONDITIONAL ACCESS BROADCASTING: DATACARE 2 
An Over-Air Enabled System for General Purpose Data Channels 

D.T. Wright. C.Eng., M.I.E.E. 



1. INTRODUCTION 

1.1 Applications 

This Report describes an over-air enabled 
Conditional Access system, known as Datacare 2, 
which was originally designed specifically for use with 
Datacast data channels 1 . It was evolved from the 
Conditional Access system specified in the MAC/ 
packet system for DBS 2 , and so has the capability of 
easy adaption to provide control signals for the sound 
and picture signal descramblers for Conditional Access 
television and sound transmissions, either terrestrially 
or via Direct Broadcast Satellite (DBS). All of the 
Conditional Access payment methods currently 
envisaged can be accommodated within the system as 
currently specified and yet there is ample scope for 
extending the specification, in an upward compatible 
way, to add new features should they become 
desirable. 



1.2 Datacast channels 

The features, characteristics and likely uses of 
Datacast channels are described fully elsewhere 1 ' 3 ' 4 . 
For applications where data from a single point is to 
be sent to many destinations, Datacast offers a cost- 
effective alternative to the use of a separate telephone 
or private wire connection to each destination. A 
single point-to point link carries data from the 
information provider to the broadcast centre and from 
here it is distributed throughout the television network. 
Standard teletext data lines are used as the transport 
medium for the data bytes in a way which is totally 
independent of the page and row structure of the 
normal teletext magazine service. Each teletext data 
line allocated to Datacast use carries a packet of up to 
36 useful bytes identified as belonging to one 
particular Datacast service. The channel is totally 
transparent to any sequence of data bytes and can be 
rendered substantially error-free by virtue of CRC 
checks on every packet and the option to repeat 
packets. The use of one teletext data line per television 
field can, for example, provide data channels for 
twelve services each equivalent to a modem operating 
continuously at 1200 baud. Allowing for diversity of 
use, for the possibility of using more than one data 
line per television field, and for the use of more than 
one television network, there is potential capacity to 
accomodate a very large number of services. The 
channels are of course uni-directional rather than full 
duplex. 



1.3 Need for encipherment 

Although teletext data lines used for Datacast 
purposes will be ignored by conventional teletext 
decoders, it is a relatively simple matter to decode 
them using teletext acquisition hardware and appro- 
priate software routines. It follows that if an 
information provider wishes to ensure privacy between 
himself and the authorised users of the information 
carried by his Datacast channel, then some form of 
encipherment must be used. 

1.4 Existing systems 

Encipherment devices are available from several 
sources for use on point-to-point data links such as a 
dial-up telephone connection with modems. These 
devices would be relatively easy to apply to a 
Datacast channel, provided that reverse communication 
is not required for the key management process. For a 
broadcast situation, however, where one encoder sends 
data to many thousands or millions of decoders, there 
was no known available system which provided for 
selective enabling or disabling of individual decoders. 
This absence of an over-channel addressable system 
was the main impetus for developing the system 
described in this Report. 



2. EVOLUTION FROM THE DBS SYSTEM 

2.1 General 

The Conditional Access system, originally dev- 
eloped with DBS transmissions in mind, was divided 
into two broad areas under the headings Scrambling 
and Encryption. Encryption referred to the distribution 
of keys and control words and Scrambling to the use 
of these control words to generate sequences used in 
the process of restoring sound and picture signals. 

In the MAC/packet receiver there are separate 
sound and picture descramblers. Each involves high 
speed signal processing circuits which are controlled 
by data at rates in excess of 200 kbit/s. This data is 
obtained from an arrangement of pseudo-random 
binary sequence (p.r.b.s.) generators and these genera- 
tors are provided with a new initial condition, known 
as a control word, every 256 television frames (i.e. 
every 10.24 seconds). Each control word is 60 bits long. 

Encryption for the MAC/packet system 
involves the use of a Conditional Access sub-system 
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together with one or more enciphered data channels. 
This arrangement contrives to provide the control 
word data to only those users who are authorised to 
receive the service. 

The picture and sound descramblers and their 
associated p.r.b.s. generators are fully specified for the 
MAC/packet system and have no direct relevance to 
this Report. On the other hand, the encipherment 
methods used to convey the control words to the 
MAC/packet receiver, which are relevant, are less 
fully defined in the MAC/packet specification. Possible 
techniques were outlined and these have been used as 
the basis from which the system described and 
specified in this Report was developed. Inevitably not 
all of the DBS techniques were suitable for application 
to a general purpose data channel, such as is provided 
by Datacast, and further development has been 
necessary. It has since been realised that some of these 
new techniques could also have been applied, with 
benefit, to the MAC/packet system. The major 
common factors and changes are discussed below. 

input data 
multiplex 



2.2 Key layers 

The basic key management techniques used for 
over-air enabling have been based upon those 
originally proposed for the MAC/packet system. The 
complete process is shown diagrammatically in Fig. 1 
and is summarised in Section 4.9. Four key layers are 
involved: unique key, shared key, period key and 
message key. For the DBS service the equivalent 
layers were respectively known as unique key, shared 
distribution key, supplementary authorisation key and 
descrambling control word. Lower level keys are sent 
to the decoder by enciphering them with a key at a 
higher level. Only the highest level key, the unique 
key, is permanent for the life of the decoder and the 
lowest level key, the message key, is changed possibly 
as often as every ten seconds. 

2.3 Key labelling 

The DBS system took advantage of the highly 
synchronous nature of the television system to 
determine when a new descrambling control word 
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Fig. 1 - Diagrammatic representation of key layers and block types. 

-2- 



(message key) should take over from an old one. In a 
data channel there is no such inherent source of 
rigorous timing and a technique of key labelling has 
been used to identify the correct key for use with any 
particular block of data. As a result keys can, 
if desired, be sent considerably in advance of when 
they are needed without causing confusion at the 
decoder. 

2.4 Data protocol 

In the original DBS system, Conditional 
Access data was formatted synchronously with the 
boundaries of MAC system packets. For example, a 
complete packet containing 90 bytes was addressed to 
one unique user or a shared group of users even 
though the data needing to be sent to one address 
normally occupies only 40 or 50 bytes. Efforts to 
make optimum use of the variable amount of spare 
capacity inevitably led to compromises, inefficient use 
of the data channel and an over-complicated specifi- 
cation. These formatting limitations have been removed 
in the present system by the use of a simple secondary 
data protocol which permits the use of variable length 
data blocks. This requires an overhead of only two 
bytes per block to achieve block separation and block- 
type identification. 

2.5 Error control 

Data formatted in this secondary protocol can 
be carried directly by any byte-organised transparent 
data channel. For channels with inadequate error 
performance an additional error-control layer can be 
implemented between the formatting of the variable 
length blocks and the channel itself. Such error 
protection would normally be considered part of the 
carrying channel rather than of the transparent byte 
stream. In particular it would then be possible for the 
error protection process to be variable depending on 
channel operating conditions, such as the location of 
receivers to which data is addressed and the prevailing 
weather conditions at this location. The original DBS 
system provides no such option to alter dynamically 
the level of error control since each of the two types 
of control message used has its method of error 
control specifically defined as part of the way the data 
is formatted into the MAC system packets. 

3. THE CONDITIONAL ACCESS 
SUB-SYSTEM 

3.1 Principles 

This system assumes the use at the receiving 
point of a detachable microprocessor module in which 
all the key management, key storage and decipherment 
processes are performed. This 'Conditional Access sub- 
system' has, as its input, data bytes from a general 



purpose transparent data channel such as is provided 
by Datacast. These bytes are transferred to the sub- 
system using serial asynchronous communication at 
9600 baud. The data output is also serial, asynchronous 
and byte organised. The processing of the input bytes 
to provide output bytes is performed by a single-chip 
8-bit microprocessor with all the controlling software, 
constants and key data held in non-volatile read/ write 
memory. The software is loaded on a one-time basis 
into a "hardware blank" using the serial input port in 
conjunction with a loader program held in a small 
amount of read-only memory (ROM). A total of 
8 Kbytes of non-volatile memory is provided, of 
which 768 bytes are reserved for the stack and 
input/output buffers. The remainder is loaded with 
application software; the loading process takes about 
nine seconds. Obviously, if many different providers of 
conditional access services can make use of a common 
hardware module, then the manufacturing cost of this 
module can be kept to a minimum. The arrangement 
used here enables one universal hardware design to 
serve various applications simply by loading different 
application software for each case. 

3.2 Main functional modules 

The essential functional modules of a Con- 
ditional Access sub-system for Datacare 2 are listed 
below under three headings: hardware, ROM-based 
software and application software. 

Hardware 

a) Means to form a serial data input into bytes and 
to provide a serial data output from output data 
bytes, both at baud rates up to 9600 baud. 

b) Non-volatile storage for key values, for the 
unique and shared addresses, for any over-air 
credit values and for all the decoding software. A 
total of 8 Kbytes of non-volatile storage should 
be available. 

ROM-based Software 

c) FIFO buffers for data bytes at the input and 
output; each buffer to hold up to 256 bytes. 
These are required both to handle irregularities 
in data rates at the input or output and to 
smooth out peak loadings in the internal data 
processing. 

d) A routine to load application-specific data 
processing software into the non-volatile 
read/write memory. This loading process to be 
executed when a self check of existing memory 
contents fails. 

e) A cyclic redundancy routine for use in the self- 
check of memory integrity. 
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Application Software 

(in non-volatile read/write memory) 

f) Data for the Unique Key and Unique Address. 

g) A routine to check, each time the processor is 
restarted, the integrity of the software stored in 
non-volatile read/write memory. 

h) Means to identify, within the incoming data 
stream, the start of each new message or control 
block and to remove the duplicated DLE 
characters inserted to provide data transparency 
(see Section 4.2). 

i) Means to bypass the entire decipherment opera- 
tion when message key blocks are not recognised 
at the decoder input (see Section 4.3.1). 

j) Means to enable decoding by the conditional 
access sub-system only when the sub-system code 
contained in the message key blocks of the input 
data matches that of the sub-system (see 
Section 4.3.2). 

k) Software routines for the appropriate processing 
of each type of data block defined for the 
application. 

1) Software to implement the decipherment 
algorithm for the 64-bit block cipher defined for 
the application. 

m) Means to configure the decipherment algorithm 
as a cipher stream generator and to exclusive-OR 
the cipher stream bytes with message data bytes 
to provide deciphered message data at the 
equipment output. 

3.3 Security 

There is a recognised security hazard which 
affects the design of the decoder modules and the way 
their application software is loaded. This is the illegal 
production of decoder modules, ('clones'), which are 
functionally identical to one particular genuine decoder. 
Payments to enable a subscription service or provide 
over-air credit to the one genuine decoder would 
automatically provide the same facilities to all the 
cloned decoders. The essential step in making cloned 
decoders is to obtain a copy of the application 
software for a particular genuine decoder since this 
contains all the decipherment algorithms together with 
the unique key and unique address. It follows that the 
application software must be loaded only within 
secure premises and that the decoder hardware must 
be tamper-proof so that, once loaded, no further access 
can be gained to the software. 

Application software should never be loaded 
via an over-air data channel even though, in technical 
terms this would be easy to achieve. For any 



particular conditional access service (i.e. one particular 
sub-system code) there should, ideally, be only one 
place where application software is loaded. Partial 
reloading of application software must not be possible 
as this would allow a simple routine to be loaded to 
cause a dump of the remaining software to the serial 
output port. Steps must be taken to prevent the 
software being read by physically probing or altering 
the decoder hardware. 

If cloned decoders are discovered and their 
unique address is known it is a simple matter to 
disable them, by radiating appropriate signals. 

The ultimate deterrent to potential manu- 
facturers of clones, however, is that, even if they are 
successful, new encipherment algorithms will be 
brought into use from time to time (as identified by 
new sub-system codes). New decoder modules will be 
issued and the old ones might be recalled for re- 
programming to suit the new standard. The routine re- 
issue process can be accelerated if an outbreak of 
cloned decoders is suspected. When a black market 
decoder suddenly stops working, who will buy one a 
second time? 

3.4 Current hardware 

A prototype decipherment sub-system is shown 
in Fig. 2. This is one of a batch of ten which were 
constructed for use in experiments to verify and 
demonstrate the specification for the Datacare 2 
system as described in Section 4. Each sub-system 
includes 8 Kbytes of read/write memory (RAM) 
which has been made non-volatile by the inclusion of 
a lithium battery; the battery life is over seven years. 
The cost of the components for each unit, including 
the battery but excluding the printed circuit board, 
case and panels, was £22. 

These units do not have sophisticated protection 
against possible cloning. Once the case is open it is a 
relatively simple matter to determine the software. A 
small degree of protection is provided by arranging 
that a link supplying power to the RAM is broken as 
the case is opened. 

3.5 Smart Cards 

It is anticipated that the circuit functions 
provided by the prototype units shown in Fig. 2 will 
soon be available in an encapsulation the size of a 
standard credit card (a 'smart card') at a cost of under 
£5. The smaller physical size should make it easier to 
render the unit tamper-proof. Currently available 
smart cards, as shown in Fig. 3, have adequate 
processing power for this encipherment system but do 
not include sufficient bytes of non-volatile read/write 
memory for the application software and key storage. 
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Fig. 2 - Decipherment module 

for Datacare 2 showing how it 

is inserted into an RS232 

data path. 




Connections to and from existing smart cards are via 
six gold-plated contact pads. It has been suggested that 
these open contacts are liable to contamination and 
that they increase the risk of the electronic function 
being damaged by static electricity. 

3.6 Inductive coupling 

It should also be possible in the near future to 
obtain processing units where the electrical connections 
for input data, output data and the operating power 
supply are replaced by a system of inductive coupling. 
These are expected to be available in the form of a 
coin or key fob in addition to the standard credit card 
format. Prototypes have been demonstrated by various 
manufacturers and Fig. 4 shows some examples of 
these. 



standard Datacast uses where there will normally be a 
readily available electrical connection path into which 
to insert the decipherment module. For the control of 
television scrambling systems, however, a different 
sub-system is likely to be required for each broad- 
casting organisation. Here inductively coupled smart 
cards or tokens offer the potential for a considerable 
improvement in user friendliness 5 . It may even be 
possible to use several such units together within a 
common magnetic field, thereby avoiding the need for 
a separate receptacle for each one. If all cards or 
tokens were to work with a data format compatible 
with this specification, then all could be presented 
with the same input data and the only token to 
respond would be the one with the correct sub-system 
code. Details of this universal recognition process 
appear in Section 4.3.3 below. 



Other than avoiding problems of contact 
contamination and damage from static electricity, the 
use of inductive coupling offers little benefit for 



For use on a data channel the data output rate 
might at times be very close to the input data rate 
and, as a result, the inductive coupling might need to 



Fig. 3 - Smart Card with electrical 
contact pads. 
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Fig. 4 - Inductively-coupled units. 



operate at 9600 baud, full duplex. At the time of 
writing none of the prototype inductively coupled 
systems offers full duplex communication at this speed. 
On the other hand, for use with an over-air enabled 
conditional access system for television, although the 
input data rate would remain at 9600 baud, the 
output data rate need be sufficient only to transfer one 
control word to each descrambler during a ten second 
interval. On this basis a data output rate equivalent to 
continuous use at 300 baud would be ample. (This 
estimate is based on the use of a maximum of eight 
descramblers to cover, for example, television picture, 
television sound, subtitles and supporting data services; 
each control word transfer would use 1 1 bytes.) 

3.7 High speed data channels 

At very high message data rates, where totally 
software-based processing may not be fast enough, the 
input to the tamper-proof processing system could be 
at the level of control blocks (point 'X' in Fig. 1), 
with the output at the level of the message key 
(point 'Y' in Fig. 1). The cipher stream generator 
would then be implemented externally using a second, 
hardware-based, version of the decipherment algorithm. 



4. DATA PROTOCOL FOR OATACARE 2 

4.1 Principal characteristics 

a) The data channel is byte organised and structured 
into blocks by means of block separator bytes 
followed by block-type bytes. 

b) One value of block-type byte is reserved to 
protect data transparency by identifying the use 
of a byte equivalent to the block separator byte 
within the body of a block. 

c) Other values of block-type byte identify up to 
255 possible kinds of data block; ten are 
specified for DATACARE 2. 



d) One type of block carries only plaintext, all 
others use encipherment. 

e) Enciphered blocks use one of three addressing 
modes: 

NO address - for all users of the 

channel 

3-byte SHARED address - for a group of up to 

256 users 

5-byte UNIQUE address - for an individual user 

f) Three kinds of message block carry enciphered 
message data, one for each of the above 
addressing categories. 

g) Message blocks are enciphered by a 64-bit block 
encipherment algorithm connected in the output 
feedback mode to create cipher stream bytes 
which are exclusive-ORed with the message data 
bytes. 

h) Six kinds of control block carry key data and 
other control information enciphered with a 
further key, previously made available. 

i) Control blocks are enciphered by a 64-bit block 
encipherment algorithm used in a differential 
code book mode. 

j) The block encipherment algorithm uses keys of 
up to 64 bits in length. 

k) Four types of key are used to encipher data in 
the message blocks and control blocks: 

Message Key - used to encipher a message block 

addressed to all users 
Period Key - used to encipher control blocks 

addressed to all users 
Shared Key - used to encipher any block 

addressed to a shared group of 

users 
Unique Key - used to encipher any block 

addressed to an individual user 
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1) The lifetime of the keys increases in the order 
listed above; only the unique key is permanent 
for the life of the decoder. 

m) There may be more than one version of period 
keys and message keys; the correct version is 
identified by matching arbitrary single byte labels. 

4.2 Block separation 

4.2.1 Block separator byte 

The block separator byte is the Standard 
ASCII character DLE ('data link escape') which has 
the decimal value 16 (hexadecimal 10). When a block 
separator byte is found its presence is used to initiate 
the decoding of the immediately following byte as a 
block type byte. The block separator byte is then 
discarded. 



4.2.2 Block-type byte 

The block-type byte follows a block separator 
byte. It should be decoded in all eight bits to 
determine the nature of the block of data up to the 
next DLE character. Table 1 lists all the values of 
block-type byte currently specified for this system; 
current generation decoders should ignore any data in 
blocks where the block-type byte is not one of those 
listed in Table 1. The contents of the block types 
specified are dealt with in the sections of text and 
figures referenced by the table. In general, the block- 
type byte is discarded after establishing the appropriate 
action for the block which follows. 

4.2.3 Data channel transparency 

One value of block-type byte must be reserved 
in order to indicate situations where a byte with a 



Table 1: Decoding of Block-Type Byte 



Block-Type 
Code 


Block 
Name 


Data 
used 


Addressing 

Mode 


Encipherment 


Format Detail 


binary 


hex. 




for 




Mode 


Key 


Section 


Fig. 


blocks containing enciphered data 














0101 0111 


57 


Common Message 


Message 


All 


OFB 


Message 


4.5 


6(a) 


0101 1000 


58 


Message Key 


Control 


All 


DCB 


Period 


4.7.1 


7(a) 


0101 1001 


59 


Key Conversion 


Control 


All 


DCB 


Period 


4.7.2 


7(b) 


0101 1010 


5A 


Period Key (shared) 


Control 


Shared 


DCB 


Shared 


4.7.3 


7(c) 


0101 1011 


5B 


Shared Message 


Message 


Shared 


OFB 


Shared 


4.5 


6(b) 


0101 1100 


5C 


Period Key (unique) 


Control 


Unique 


DCB 


Unique 


4.7.4 


7(d) 


0101 1101 


5D 


Shared Key 


Control 


Unique 


DCB 


Unique 


4.7.5 


7(e) 


0101 1110 


5E 


Over- Air Credit 


Control 


Unique 


DCB 


Unique 


4.7.6 


7(f) 


oioi mi 


5F 


Unique Message 


Message 


Unique 


OFB 


Unique 


4.5 


6(c) 


interpretation of other block-type codes 














0001 0000 


10 


The previous DLE c 
the contents of the 


haracter was not a block separator and should be treated as 
current block. 


part of 


0101 0000 


50 


Any following bytes up to the next block separator should be treated as an un-enciphered 
channel. Also used with no following bytes to terminate a previous block if no other data 
is available. 



OFB - Output Feed Back 
DCB - Differential Code Book 



1 Encipherment modes for 64-bit block cipher, 
J see Section 4.4.2 
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value equivalent to the block separator is required 
within the body of a data block and is not to be 
interpreted as a block separator. This value is 
conveniently chosen as a repeat of the byte value 
whose transparency it protects. Thus for this system, 
each time that a byte value of 10 hex. is required in 
the body of a block, the ASCII character DLE is sent 
twice. In a typical decoder the first DLE character will 
be recognised as a block separator and will initiate 
decoding of the next character as a block-type byte. 
When this byte is found to be a second DLE 
character, it can be used to replace the block separator 
byte already wrongly discarded. Decoding of the 
current block then continues as if no block separator 
had occurred. 

4.3 Channel and sub-system recognition 

4.3.1 Encipherment standard 

In addition to their main purpose of conveying 
a message key, Message Key Blocks (for which the 
format is defined in Section 4.7.1 below) serve as the 
means by which a data channel formatted to this 
specification is recognised. Message key blocks were 
chosen to serve this purpose because they will occur 
frequently in any channel formatted to this specifi- 
cation. 

If no new message key block starts within 
1000 data input bytes from the start of a previous 
message key block or from acquisition of the channel 
then the channel should be assumed to be either un- 
enciphered or enciphered to a non-compatible standard. 
For certain applications, it might be appropriate in 
such cases that the decipherment sub-system provides 
an output which is an exact copy of the input byte 
stream; any such 'bypass mode' should cease as soon 
as a message key block is detected. 

4.3.2 Correct sub-system 

The message key block contains a sub-system 
code which should match that of a connected sub- 
system. That sub-system would then be enabled for 
the purpose of decoding all other types of data block 
and for providing any resulting output bytes. When 
the sub-system codes do not match, the output should 
be inhibited and no attempt made to process further 
data from the message key block or any data in other 
block types. 

4.3.3 Compatibility with other systems 

By ensuring that all sub-systems obey the 
channel recognition requirements given above, there is 
considerable capability for the evolution of alternative, 
but compatible, standards. To ensure this compatibility, 
the data stream for such an alternative standard needs 



to contain regular occurrences of the three-byte 
sequence 

DLE, 58 H , ss 

where: 

DLE is the block separator byte, 

58 H is the block-type byte value for a 
message key block 



and 



ss is a previously unused sub-system code. 



This sequence of bytes will ensure positive disabling of 
any existing sub-system operating to this specification. 
All other block-type byte values can then have their 
meanings and formats re-defined to suit the particular 
use. Furthermore, the format of any data following 
this compatible byte sequence need not be the same as 
that of the message key blocks in this specification. 

It may be advantageous to reserve some sub- 
system code byte values, say the top 64 of the 256 
possible values, for future systems where a second sub- 
system code byte is used. This would allow for 192 
systems or versions of systems with a one-byte sub- 
system code and a further 16 384 variations with a 
two-byte sub-system code. 

4.4 Decipherment algorithm 

4.4.1 General 

The decipherment algorithm may be any block 
cipher which converts a 64-bit input word into a 
64-bit output word under the control of a key of up 
to 64 bits in length. 

In terms of performance, the DES algorithm 
specified by the USA National Bureau of Standards 6 
would have been suitable for this function but, for 
various reasons, this algorithm is not available for use 
in Datacare 2 applications. Alternative algorithms 
based on a 64-bit block cipher have been devised. In 
general the details of such 'DES replacement' 
algorithms need not be published but one possible 
method is outlined in Appendix 1. 

4.4.2 Rhodes of use 

An ISO draft international standard, ISO 
DIS 8372, which is based on an earlier American 
document 7 , specifies four possible modes of use for a 
64-bit block cipher. One of these, the Output 
Feed Back mode (OFB), has been used in this system 
but it has been found necessary to define an additional 
mode to achieve a characteristic of unlimited error 
extension not provided for in the ISO draft standard. 
This new mode has been named Differential Code 
Book (DCB). The two modes used in this system are 
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described below together with the basic Electronic 
Code Book mode (ECB) from which they are derived. 

ECB - The Electronic Code Book mode is the 
simplest method of use for a block encipher- 
ment algorithm. Eight input bytes are con- 
verted by the algorithm to form eight output 
bytes without any reference to the preceding 
conditions. Fig. 5(a) gives a block diagram of 
the process. This method provides no extension 
of errors in the input data beyond the eight 
byte block in which the error occurred. A 
single error within a block will, however, 
cause gross errors at the output for that block. 

OFB - The Output Feed Back mode is used to 
generate a cipher stream which can then be 
exclusive-ORed with message data to achieve 
scrambling or descrambling. The arrangement 
is shown in Fig. 5(b). First an initial variable 
is converted by the algorithm to provide the 
first eight bytes of the cipher stream. These 
eight bytes are then converted again to form a 
further eight bytes and so on. Provided that 
the initial variable is correct, no errors can 
enter the cipher stream generation process and 
there is no extension of errors in the message 
data. 

DCB - The Differential Code Book mode is a 
modification to the standard Electronic Code 
Book mode. In the decoder, the data bytes to 
be deciphered by the algorithm are first 
combined by an exclusive-OR operation with 
the result of the previous conversion, as 
shown in Fig. 5(c). In the absence of an 
earlier conversion this is taken as all zeros, so 
the first DCB output is simply the ECB 
output. This procedure provides unlimited 
extension of any errors in the input data. This 
mode is used to ensure that any error in the 
early part of a data block, which may be due 
to the input data stream having been 
tampered with, will corrupt essential data 
placed at the end of the block. 

4.5 Message blocks 

Three kinds of message block are specified, 
one for each mode of block addressing. Message 
blocks can be omitted where this system is used only 
to provide control words for picture and sound 
descramblers. In general the only type of message 
block present will be that addressed to all users of the 
channel (common message block). In rare circum- 
stances a message may be sent to an individual user 
(unique message block) or to all users with a specific 
shared address (shared message block). 
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Fig. 5 - Modes of use for block encipherment algorithm. 

(a) Electronic Code Book (ECB) 

(b) Output Feed Back (EFB) 

(c) Differential Code Book (DCB) 



The contents of each of the three types of 
message block are listed overleaf. 

The data in message blocks is enciphered using 
a 64-bit block cipher in the Output Feed Back (OFB) 
mode (see Section 4.4.2). The key used is appropriate 
to the addressing mode (see Table 1). As common 
message blocks are deciphered using a message key 
for which more than one version may be available, 
they include a message key label to identify the 
correct version. For the Shared or Unique message 
block the relevant address bytes follow the block-type 
byte in place of the message key label. The remaining 
data has the same format for all three types of 
message block. The eight-byte initial variable is made 
by an eightfold repetition of the initial variable byte 
which is sent immediately before the enciphered 
message. 

To reduce the effects of any loss in synchro- 
nisation, long messages will be divided into several 
shorter blocks using the same key but each with its 
own value of initial variable for the cipher stream 
generator. 
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Common Message Block - Fig. 6(a) 



Data Item 


Bytes 


Block separator 
Block type (57 H ) 
Message key label 
Cipher stream initial 


1 

i 
I 


variable 


1 


Message data 


n 



TOTAL n+4 



any number of bytes 
enciphered by exclusive-OR 
operation with cipher stream 
generated by appropriately 
labelled message key 



Shared Message Block - Fig. 6(b) 



Data Item 


Bytes 


Block separator 


1 


Block type (5B H ) 


1 


Shared Address 


3 


Cipher stream initial 




variable 


1 


Message data 


n 



TOTAL n+6 



any number of bytes 
enciphered by exclusive-OR 
operation with cipher stream 
generated by shared key 



Unique Message Block - Fig. 6(c) 



Data Item 


Bytes 


Block separator 
Block type (5F H ) 
Unique Address 

Cipher stream initial 


1 
1 

5 


variable 


1 


Message data 


n 



TOTAL n+8 L 



4.8 Sub-services 



any number of bytes 
enciphered by exclusive-OR 
operation with cipher stream 
generated by unique key 



When using Common Message Blocks with 
this system, up to 127 sub-services can be configured 
by arranging that data items falling into different 
subject categories are scrambled by cipher streams 
derived from different message keys. Delivery of the 
message keys and hence access to the sub-services can 
then be made selective by a combination of a sub- 
service pointer byte in the block which delivers the 
message key (see Section 4.7.1) and a 127-bit sub- 
service enabling mask previously stored in the 
decoder's non-volatile memory. The sub-service mask 
is set up and changed by means of uniquely addressed 
control blocks (see Sections 4.7.4 and 4.7.5). 

Sub-services can be used either to prevent a 
user from being swamped with unwanted data or to 
deny access to data categories which have not been 



block-type [-message key label 
byte=57 H ] | rcipher stream initial variable 

J, -j , 



variable length message data 



bytes enciphered by exclusive-OR 

operation with cipher stream 

generated by message key 

(a) 



block-type ,-shared address 

byte = 5B H l rcipher stream initial variable 



variable length message data ||l 



bytes enciphered by exclusive-OR 

operation with cipher stream 

generated by shared key 

(b) 

block-type r-unique address 

byte = 5F H I rcipher stream initial variable 



! I 

variable length message data 



bytes enciphered by exclusive-OR 
operation with cipher stream 
generated by unique key 

(c) 

Fig. 6 - Message data Mock formats. 

(a) Common Message Block 

(b) Shared Message Block 

(c) Unique Message Block 

authorised or paid for. The latter use allows the 
provision of facilities equivalent to a tiered subscription. 

4.7 Control blocks 

Six types of data block are currently specified 
for control purposes. All commence with between two 
and five bytes of address and/or key label information 
and this is followed by data enciphered using the DCB 
mode (see Table 1). Since a 64-bit block encipherment 
algorithm is used, it follows that the enciphered 
portion of the block must contain a multiple of eight 
bytes. In order to pad out the enciphered portion, part 
of the key used to encipher the block is included 
within the enciphered data field. These bytes serve as 
key validation indicators. (Because, in practice, at least 
four such bytes are used in all cases, it is most 
improbable that a wrong key would decipher these 
bytes to match its own corresponding bytes.) 

In any group of bytes the least significant is 
transmitted first. The six types of control block 
specified are discussed in the following sub-sections 
with format details in Figs. 7(a) to 7(f). 
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4.7.1 Message Key Block - Fig. 7(a) 

The contents of the message key block are as lis- 
ted below. Its main function is to carry a message key 
enciphered by a period key to all users of the system. 



Data Item 


Bytes 




Block separator 






Block type (58 H ) 






Sub-system code 






Period key label 






Message key label 






Part period key 


5 - 




Sub-service pointer 


1 


16 bytes enciphered with the 


Key price 


2 


period key 


Message key 


8 J 





TOTAL 21 

In each sub-system, the transmitted sub-system 
code should be checked against the code of that sub- 
system. Decoding by a sub-system of any control or 
message blocks should be inhibited unless the sub- 
system code matches that given in the message key 
blocks (see Section 4.3.2). 

The period key label allows selection of the 
correct version of the period key required to decipher 
the block when more than one is available. 

The message key label is used to identify 
which version of the message key is being delivered. It 
is placed outside the enciphered field so that a 
disabled decoder (i.e. one which does not have the 
correct period key) can clear a previous key already 
stored against the given label. This prevents 'garbage' 
output being produced where no output was intended, 
due to the incorrect use of an old key following non- 
delivery of a new one. 

Validity of the period key is verified by 
including the five least significant bytes of it within the 
enciphered field. 

The sub-service pointer byte defines the sub- 
service category for which the message key is being 
delivered. For values between zero and 127 it points 
to a bit in the user's sub-service mask (see Sections 
4.7.4 and 4.7.5). In such cases the decoder should 
make the message key available only if the corres- 
ponding mask bit has been set. A pointer byte value 
of zero corresponds to the least significant bit of the 
first transmitted byte of the sub-service mask and a 
pointer byte value of 127 corresponds to the most 
significant bit of the last transmitted (sixteenth) mask 
byte. Pointer values of 128 to 255 also define, 
respectively, sub-services zero to 127 but without 
restriction on delivery of the message key. 



The key price applies to a pay-per-key system; 
the two bytes are taken as binary values; the first 
represents fractional parts (1/256) of a unit and the 
second whole units. When the message key is ready to 
be made available its price should be deducted from 
the sub-system's register of credit remaining. If there is 
insufficient credit the key should be withheld. 
Exhausted credit can be replenished either by 
exchanging the sub-system or by the use of over-air 
credit blocks (see Section 4.7.6). 

4.7.2 Key Conversion Block - Fig. 7(b) 

On at least two occasions before a change of 
period key, priority is given to sending the new period 
key to all subscribers in turn, either singly or in shared 
address groups. At such times, when data blocks type 
5Ah or 5Ch in Table 1 carry the new period key, 
decoders that are new to the system may not have had 
a chance to receive and store the current period key. 
Key conversion blocks are included in the data 
multiplex at these times to make the current period 
key available to decoders which have received the 
new period key. 



Data Item Bytes 

Block separator 1 

Block type (59 H ) 1 

Source key label 1 

Result key label 1 

Result key 8 



eight bytes enciphered with 
the source key 



TOTAL 12 



The block contains the current key (result key) 
enciphered by the new key (source key) and labels 
for the two keys. No key-check bytes are included 
since successful operation can be confirmed by 
applying the result key to a message key block; these 
blocks contain check bytes, are addressed to all 
users, and occur regularly. Because the conversion 
block is short and common to all users, it can appear 
relatively frequently without undue waste of channel 
capacity. 

4.7.3 Period Key Biock (shared) - Fig. 7(c) 

This is one of two kinds of period key block, 
in this case used to send a period key to a group of 
users with a common shared address by enciphering it 
with the shared key for the group. Shared addressing 
is used to speed up the process of sending new period 
keys to large numbers of users. 

Validity of the shared key is verified by 
including the seven least significant bytes of it within 
the enciphered field. 
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block-type 
byte = 58 H 



v v 



(-sub- system code 
period key label 
message key label 

sub-service pointer 
key price 
message 
key 
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period 

key 



block-type 
byte = 59 H " 



.-source key label 
■result key label 
resujt key 



ir W/- 



2 @ eight-byte blocks 
enciphered with the period key 



eight bytes enciphered 
with source key 



(b) 



block-type_ 
byte = 5A H 



part shared key 



shared 
address 



period key label 

user-enabling mask 



period key 






6 (a) eight-byte blocks enciphered with the shared key 
(c) 



block -type upj 
byte=5C H l address 



■part unique key 

period key label 

sub-service mask 

^♦, -~ 



i i i 
» » » 



period key 



4 (9) eight-byte blocks enciphered with unique key 
(d) 



part unique key- 
block-type unique 
byte = 5D H laddress 



rshared address 

enabling bit pointer 
sub-service mask 



shared key 






i i 

i i 



4(5) eight-byte blocks enciphered with unique key 
(e) 



block- type unjque 



byte = 5E H 



address 



old value total credit 



unique key 



LS 
bytes 



' I r i 
I i I i 

_1 ! I l_ 



MS 
bytes 



new value 
total credit 



2 O eight -byte blocks 
enciphered with unique key 

(f) 

Fig. 7 - Control data block formats. 

(a) Message Key Block 

(b) Key Conversion Block 

(c) Period Key Block (shared) 

(d) Period Key Block (unique) 

(e) Shared Key Block 

(f) Over-air Credit Block 
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Data Item 


Bytes 


Block separator 


1 


Block type (5Ah) 


1 


Shared address 


3 


Part shared key 


7 


Period key label 


1 


User enabling mask 


32 


Period key 


8 



48 bytes enciphered with the 
shared key 



TOTAL 53 

The period key label is used to identify which 
version of the period key is being delivered. 

A group may contain up to 256 users. The 
256-bit user enabling mask allows acquisition of the 
key to be restricted to any combination of users within 
the group. The bit position in the mask which applies 
to any particular user is given by that user's enabling 
bit pointer which is sent via a shared key block 
together with the shared address and shared key (see 
Section 4.7.5). Bit position zero is the least significant 
bit of the first transmitted mask byte. 

4.7.4 Period Key Block (unique) - Fig. 7(d) 

This second kind of period key block is used 
to send a period key to a single user, together with the 
user's sub-service mask, by enciphering both with the 
unique key. This user-by-user method of sending 
period keys is intended primarily for systems with 
relatively few users. 



Data Item 


Bytes 




Block separator 


1 




Block type (5C H ) 


i 




Unique address 


5 




Part unique key 


7 - 




Period key label 


1 


32 bytes enciphered with the 


Sub-service mask 


16 


unique key 


Period key 


8 J 





TOTAL 39 

Validity of the unique key is verified by 
including the seven least significant bytes of it within 
the enciphered field. 

The period key label is used to identify which 
version of the period key is being delivered. 

The sub-service mask depicts, by an array of 
128 bits, the selection of 128 possible sub-services for 
which the user is permitted to obtain the message key. 
The complete mask should be stored for later interro- 
gation under control of sub-service bytes in message 
key blocks. Sub-service zero corresponds to the least 
significant bit of the first transmitted mask byte. 



4.7.5 Shared Key Block - Fig. 7(e) 

The shared key block is used to send a shared 
key and the corresponding shared address and 
enabling-bit pointer value direct to a single user by 
enciphering it with the unique key. Also included is 
the user's sub-service mask. 



Data Item Bytes 

Block separator 1 

Block type (5D H ) 1 

Unique address 5 

Part unique key 4 

Shared address 3 

Enabling-bit pointer 1 

Sub-service mask 16 

Shared key 8 



32 bytes enciphered with the 
unique key 



TOTAL 39 

Validity of the unique key is verified by 
including the four least significant bytes of it within 
the enciphered field. 

The enabling bit pointer is, in effect, an 
extension to the shared address that identifies which 
bit in the user enabling mask of the period key block 
(shared) applies to the particular user (see Section 
4.7.3). A pointer value of zero corresponds to the least 
significant bit of the first transmitted mask byte. 

Use of the sub-service mask is as for the 
unique period key block (see Section 4.7.4). 

4.7.6 Over-air Credit Block - Fig. 7(f) 

The over-air credit block carries the all-time 
running total (modulo 2 32 ) of over-air credit transfers 
for a particular sub-system. This allows the block to 
be repeated without more than one increase in credit 
being accumulated. To provide good security against 
false revisions of the credit value, the enciphered part 
of the block also carries the previous all-time credit 
total and the complete unique key for the user. The 
credit total remaining should be adjusted only if the 
key check and the old running total are both correct. 
It is then increased by the difference between the new 
and previous total credit values. 



Data Item Bytes 

Block separator 1 

Block type (5E H ) 1 

Unique address 5 

Previous total credit 4 

Unique key 8 

New total credit 4 



16 bytes enciphered with the 
unique key 



TOTAL 23 
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4.8 Key and data storage 

Table 2 shows the data items which can 
change as a result of received control blocks and for 
which the values must be retained when the power is 
removed. Note that with the exception of period keys, 
message keys and their relevant labels, there is only 
one version of each data item. Key labels with a value 
of zero are reserved to identify invalid key values. This 
means that storage for up to 255 separate period keys 
and 255 separate message keys could be provided. The 
storage actually allocated for each will be a design 
parameter for the particular application (related to the 
sub-system code). The storage allocated must, of 
course, be known to the transmitting equipment. The 
quantities given in Table 2 relate to a typical 
application where storage is provided for two versions 
of the period key and sixteen message keys. 

When a new key is received it may have a 
label which matches that of a currently stored key of 
the same type. In this case the new key value should 
be used to replace the old one against the same label. 
When the label for the new key does not match any 
existing label the storage space with the oldest written 
label should be used. This is, in effect, a first-in first- 
out function with regard to the storage of labels but 
not necessarily so for the key data itself because the 
key value held against a previously existing label may 
have been revised. 



Table 2: Data Items Stored Within Tamper-proof 
Sub-system for a Typical Implementation ofDatacare 2 



Item stored 


Number of 


Bytes per 


Total 




versions 


version 


bytes 


Unique key 
Unique address 
Sub-service mask 


1 
1 

1 


8 

5 

16 


8 

5 

16 


Shared key 
Shared address 


1 

1 


8 
3 


8 
3 


Enabling-bit pointer 
Period key + label 
Message key + label 
Total credit register 
Credit balance register 


1 
2 
16 
1 
1 


1 
8+1 
8+1 
4 
4 


1 

18 

144 

4 

4 



GRAND TOTAL 211 



4.9 Summary of decoder operation 

Fig. 8 shows a flow diagram of the decoder 
operation which can be summarised with the help of 
the following notes: 

(1) Each Datacast channel will address a particular 
family of decoder sub-systems by means of an 



eight-bit sub-system code. This is conveyed to 
the decoder in the message key blocks of the 
Datacast channel which feeds the decoder input. 

(2) For each individual sub-system within the 
selected family there will be a single unique 
address and a corresponding unique key which 
are inaccessible to the user, i.e. known only to 
the broadcaster. 

(3) The unique address and unique key can be 
used to send a shared address and shared key 
to the sub-system. A sub-system can be in only 
one shared address group at any time as only 
one version of shared key and shared address is 
defined. 

(4) Either the unique address with the unique key 
or the shared address with the shared key can 
be used to send a number of different period 
keys to one or a group of sub-systems by 
means of period key blocks. 

(5) When sent to a shared address a period key 
will only be loaded if the user enabling mask 
which accompanies it is valid in the bit 
position relevant to the particular user. 

(6) Each period key is delivered with a corres- 
ponding eight-bit label. 

(7) A message key is recovered using a period key 
selected by its label, but the key is not made 
available if the user's sub-service category mask 
is not set for the category of service which the 
message key block defines. 

(8) Message keys are also identified by labels 
which correspond with the message key labels 
in the common message blocks to which they 
belong. 

(9) The message key controls a decipherment 
algorithm connected in the Output Feed Back 
mode so as to form a cipher stream generator. 

(10) The contents of the message blocks are 
deciphered by exclusive-ORing the enciphered 
message bytes with bytes obtained from the 
cipher stream generator. 

(11) To minimise the time taken to recover from 
losses of synchronisation, long messages are 
split into several short blocks. Each block 
provides a new initial variable for the cipher 
stream generator. 
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Fig. 8 - Flow diagram of decoding process. 



5. ACCESS TiME 

5.1 General 

For an over-air enabled Conditional Access 
system a Datacast channel might deliver data at a rate 
equivalent to asynchronous communication at 
9600 baud with about 50% of its capacity allocated to 
addressed enabling information. If the shared addressing 
technique is used, one 53-byte data block can send a 
new period key to 256 users. On this basis the 
equivalent of 4800 baud for the over-air enabling data 
would allow a new period key to be sent to one 
million users every seven minutes. 

5.2 Larger systems 

For a system such as terrestrial television 



which might develop to tens of millions of viewers, 
separate Datacast channels can be implemented 
for each successive block of, say, one million users. 
Alternatively the time taken to send a new period key 
to all users can be allowed to increase. In this way a 
Conditional Access sub-system need not process data 
at a rate higher than 9600 baud and the interface 
arrangements are kept simple. 



6. OTHER USES 

6.1 Scrambled terrestrial television 

This new system has obvious possibilities for 
the control of the scrambling of terrestrial television 
transmissions. Although originally developed to com- 
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bine scrambled data signals with all their enciphered 
control signals, including over-air enabling, within a 
single Datacast channel, it would be a simple matter 
for a Datacast channel carried by existing teletext 
facilities to carry control signals without scrambled 
message data. Message keys could be produced with 
their labels set to to match values of conditional access 
frame count (CAFCNT) which will pertain when the 
key becomes valid. These keys with labels can then be 
output directly by the conditional access deciphering 
sub-system rather than being used internally to control 
a cipher stream generator which descrambles message 
data. The labelled keys would form the control words 
for the sound and picture signal descrambling circuits 
which would use techniques similar to those originally 
proposed for DBS. 

In a terrestrial television system there is no 
existing eight-bit count of television frames (FCNT) 
from which to derive the further 20-bit conditional 
access frame count (CAFCNT) which increments 
every 10.24 seconds. These counts can easily be 
provided by a chain code 8 ; the use of two bits per 
field placed, for example, as pulses on a suitable line 
in the vertical interval would enable the full 28-bit 
combined count of FCNT and CAFCNT to be 
established in less than one second. 

6.2 Scrambled NICAM 728 

There is a recently announced system for 
carrying digital stereo sound with existing terrestrial 
television, which is known as NICAM 728. If it were 
required to scramble this service, some of the 
11 kbit/s spare data capacity which exists in this 
system could' be used to provide a transparent data 
channel which would provide the input to the 
conditional access sub-system. The output of the sub- 
system would be control words intended for applica- 
tion to a sound descrambler. The way in which these 
control words could be used to achieve descrambling 
could be very much as already proposed for the 
MAC/packet system which requires a new control 
word every 10.24 s (256 television frames). 

6.3 Simplification of DBS Conditional 
Access 

If transparent data channels similar to those 
provided by Datacast are implemented using the 90- 
byte packet structure of the MAC/packet system 
rather than the 42-byte packet structure of the teletext 
data lines, then these channels can be used to 
implement Conditional Access services on DBS which 
are directly compatible with terrestrially based ones as 
described above. Work is in hand to prepare detailed 
proposals for such general purpose transparent data 
channels within the MAC/packet system. 



7. CONCLUSION 

This Report has described and specified an 
over-air enabled Conditional Access system which can 
be applied to any general purpose data channel. The 
main features of this system are indicated in Table 3. 
Although originally developed for enciphering data 
messages carried by Datacast channels, it can be 
readily adapted to deliver, instead of text messages, 
control words to picture and sound signal descramblers. 
It may thus find use where it is required to add 
Conditional Access facilities to terrestrial television 
transmissions. 

Work is in hand to specify a general purpose 
data transport mechanism for the MAC/packet system 
and such 'Datacast-in-MAC channels could form the 
basis of an improved Access Control System for DBS. 
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Table 3: System Features ofDatacare 2 

Future-proof system design. 

Suitable for use on any error-controlled data channel. 

Encipherment performed as a separate layer. 

Byte organised protocol. 

Self contained within a single data channel address. 

Variable length data blocks for efficient use of data channel. 

Transparent to message data. 

No error extension to message data. 

System design minimises effects of lost control data. 

Control data proofed against tampering. 

Can use any 64-bit block cipher with keys up to 64 bits long. 

Key management by over-air addressing. 

Can be decoded at up to 9600 baud by single-chip microcomputer 
with additional memory. 

Adaptable for other key management techniques (post, 
telephone, etc.). 

Capable of subscription or pay-per-key. 

Provision for over-air credit transfer. 

Users can be grouped for fast over-air addressing. 

Adaptable to provide Control Word data to picture and sound 
descramblers. 

Simplified operation for systems with a low number of users. 

Enciphered channel can be configured as a set of sub-services. 
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APPENDIX 1 



Block Encipherment Algorithm 

The current draft British and International Standards on data encipherment are based on the use of a 64-bit 
block cipher in one of four modes. The key word has a length of at least 48 bits. 

One such block cipher is the US Data Encryption Standard (DES) but, for various reasons, this is not 
available for general use in the UK. 

This note proposes an encipherment algorithm which is relatively simple to implement in software, 
hardware or VLSI and which, in the case of the example described in detail, is believed to be adequately secure 
for commercial broadcasting applications. As defined here it uses 64-bit blocks and a 48-bit key (extendable to 
64-bit). The principle can be extended to other block sizes and key lengths but the example described is believed 
to be particularly efficient and appropriate. 

The heart of the operation is a device, here called the permuter, which, under the control of a two-bit 
control input, converts an eight-bit input word to an eight-bit output word using one of four stored permutations 
of the 256 input states to 256 output states. Because these are permutations, and not simply random 'look-up 
tables', the operation is reversible as, for each given control word, each output state corresponds to one and only 
one input state. For every permuter there is a simply-defined complementary permuter which, when given the 
same control bits, acts in the reverse direction to produce the 'input' which would have given each 'output'. 

The most obvious embodiment of the permuter is a 1024 by 8-bit read-only memory (ROM). This has a 
10-bit input; two of these bits are assigned to the control function and the remainder constitute the eight-bit input. 
The algorithm described here requires 24 permuters for full-speed parallel operation. As there is an enormous 
number of suitable permutations for this task it is perfectly possible, and straightforward in principle, to specify and 
load 96 different 256-to-256 permutations into the 24 permuters. However, there are obvious economies in sharing' 
fewer overall permutations, particularly where the permuters are to be time-shared in a sequential implementation 
(e.g. eight or even one at a time) or in a software implementation where the conversion tables are stored in 
memory. It is suggested that for the purposes of commercial broadcasting all the permuters can be identical, but 
the method is described in the general case where they can all be different. 

In Fig. A 1.1 the permuters are shown as 8-by-8 squares with the eight inputs on the left-hand edge and the 
eight outputs on the right-hand edge. They are stacked in banks of eight so that together they handle 64 bits at 
once. The ordered 64-bit input is applied to the 64 input points using a fixed but irregular distribution (e.g. a 
random permutation of 64 items). The outputs of the first bank of permuters (a-h) are offered as inputs to the 
second bank (j-r). It is desirable that each of the second bank permuters have one input from each of the first bank 
permuters. This is shown in the drawing by a simple transposition but a more random fixed permutation satisfying 
this constraint would be preferable but probably not necessary in this application. The same considerations apply 
to the coupling of the second bank to the third bank of permuters (s-z). The output 64 bits are assembled using 
another fixed but irregular distribution. The 48-bit key is distributed such that each of the 24 permuters receives 
two unique bits in a fixed and not necessarily irregular way. 

The principle is readily extended to a 64-bit key by adding another bank of eight permuters in the same 
pattern. 

By reading the diagram from right to left, with complementary permuters s-z applied first but still with 
their original control bits from the key word, it is clear how the process can be reversed in order to decipher the 
64-bit block with the same key that was used for encipherment. 
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Fig. A 1.1 - Block encipherment algorithm. 
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